Press Room  |  Get Java Here  | 

Printed: Nov 12, 2024
From: http://jcp.org/en/jsr/detail?id=127

Standard Format

Specification Leads
	Ed Burns	Oracle
	Craig R. McClanahan	Sun Microsystems, Inc.
Expert Group
	Apache Software Foundation	Bayern, Shawn	BEA Systems
	Bergsten, Hans	Berkovitz, Joseph	Bogaert, Mathias
	Borland Software Corporation	Carapetyan, Pete	Developmentor
	Droplets, Inc.	EDS	EMC Corporation
	Fujitsu Limited	Geary, David	Hewlett-Packard
	IBM	ILOG	Lazarus, Eric
	Macromedia, Inc.	Mettu, Kumar	Nash, Michael
	Netdecisions Holdings United	Novell, Inc.	Oracle
	Progress Software	SAS Institute Inc.	Siemens AG
	Strachan, James	Sun Microsystems, Inc.	Zukowski, John A.

Updates to the Original Java Specification Request (JSR)

Current JSR Status

The JSR-127 expert group is actively developing the Public Review Draft of the JavaServer Faces specification. In addition, early access versions of the reference implementation will become available during the process, in order to get developer feedback before the specification goes to Final Draft. For more information about early access releases, see http://java.sun.com/j2ee/javaserverfaces/.

Thank you,
The JSR-127 Expert Group

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Sun Microsystems

Name of Contact Person: Amy Fowler

E-Mail Address: amy.fowler@sun.com

Telephone Number: +1 408 343 1418

Fax Number: +1 408 343 1797

Specification Lead: Amy Fowler, Hans Muller, Java Software, Sun Microsystems

E-Mail Address: amy.fowler@sun.com, hans.muller@sun.com

Telephone Number: +1 408 343 1418

Fax Number: +1 408 343 1797

Initial Expert Group Membership:

ATG
Borland
Documentum
Macromedia
SAS
Sitraka
Sun Microsystems
WebGain

Section 2: Request

2.1 Please describe the proposed Specification:

The Servlet/JSP environment provides a powerful model for creating web applications, however it defines no APIs specifically for creating the client GUI. To build a JSP page that contains one or more HTML forms, a developer must manage the form's GUI state and build a mechanism to dispatch from incoming HTTP requests to component specific event handling methods. When constructing a web site that provides a complex GUI, developers often create special purpose infrastructure that simplifies re-using form parts and facilitates the process of applying sweeping style and behavioral changes to all of the GUI elements on the site. Over time, the specialized infrastructure created to support all of these tasks tends to take on a life of it's own. Unfortunately the idiosyncratic qualities of a particular site's GUI software make it difficult to take advantage of generic level programming tools and environments. Ideally an off the shelf tool would simplify high level tasks like arranging and reusing GUI components and interconnecting component state and input handling with the objects that define the application's behavior.

This is a proposal to define a standard set of JSP tags and Java classes that simplify building Java Server application GUIs. Beyond addressing a common problem, creating a standard way to define complex HTML forms and other common GUI elements will enable tools vendors and third party component vendors to focus their energy on a single component framework for JSP/servlets. It will also help bridge the gap between conventional GUI toolkit developers and web based GUI developers by providing familiar APIs for GUI components, component state, and for rendering and input processing. Comprehensive support for internationalization and basic input validation will ensure that developers include these features in the first release of their applications.

The following 8 design goals represent the focus of this proposal:

1. Create a standard GUI component framework which can be leveraged by development tools to make it easier for tool users to both create high quality GUIs and manage the GUI's connections to application behavior.

2. Define a set of simple lightweight Java base classes for GUI components, component state, and input events. These classes will address GUI lifecycle issues, notably managing a component's persistent state for the lifetime of its page.

3. Provide a set of common GUI components, including the standard HTML form input elements. These components will be derived from the simple set of base classes (outlined in #1) that can be used to define new components.

4. Provide a JavaBeans model for dispatching events from client-side GUI controls to server-side application behavior.

5. Define APIs for input validation, including support for client-side validation.

6. Specify a model for internationalization and localization of the GUI.

7. Automatic generation of appropriate output for the target client, taking into account all available client configuration data, such as browser version, etc.

8. Automatic Generation of output containing required hooks for supporting accessibility, as defined by WAI.

This JSR is viewed as synergistic with the JSP Standard Tag Library project (JSPTL, JSR-052), as JSPTL does not include GUI-related APIs.

Additionally, work continues in the W3C to evolve relavent web technologies (XHTML, XForms) and the expert group will track these efforts to ensure the proposed specification includes enough flexibility to evolve with these technologies as needed.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

J2EE

2.3 What need of the Java community will be addressed by the proposed specification?

This specification will establish a standard API for creating Java Web application GUIs, which will eliminate the burden of creating and maintaining GUI infrastructure for developers.

2.4 Why isn't this need met by existing specifications?

The Servlet/JSP APIs define no GUI structure beyond emitting the appropriate HTML for the client. There is no model for representing GUI elements as manipulable, stateful objects on the server, and no standard mechanism for dispatching client events back to specific methods in the server application. There are no standard APIs for supporting internationalization, localization, or accessibility.

The existing Java specifications for creating GUIs, AWT and Swing, were not designed for modeling GUI elements within an HTML page across an HTTP connection, which is a scenario requiring significantly different rendering and event models. However, since a design goal of this JSR is to provide a GUI paradigm which is familiar to developers, applicable designs and APIs, such as the JavaBeans event model, will be drawn from these and other existing GUI toolkits.

2.5 Please give a short description of the underlying technology or technologies:

See Specification description in Section 2.1.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.servlet.ui

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current security model?

No.

2.9 Are there any internationalization or localization issues?

Yes. APIs to support internationalization and localization are a key design goal of this JSR.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No such changes are anticipated. The existing GUI specifications, AWT and Swing, are targeted for traditional object-oriented GUI development and will continue to be supported.

2.11 Please describe the anticipated schedule for the development of this specification.

The final schedule will be determined by the expert group, however the target for the Community Draft specification is Fall 2001.

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

Most of the working group communication will happen via email discussion. There will be a face-to-face meeting to initiate the working group activity.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Specifications for the Java Server development environment:
JSP 1.1 Specification (http://java.sun.com/products/jsp)
Servlet 2.2 Specification (http://java.sun.com/products/servlet)

3.2 Explanation of how these items might be used as a starting point for the work.

This JSR specification will include a new Java class library which hooks in appropriately with the Servlet 2.2 API and an associated JSP Tag library based on the JSP 1.1 specification. Note that the revisions to these APIs, Servlet 2.3 and JSP 1.2, are currently in progress, however it is not anticipated that this JSR will have any dependencies on functionality introduced in these revisions.

Contact Us

© 2024, Oracle Corporation and/or its affiliates. Terms of Use. Privacy Policy. Trademarks